Today, many network infrastructures (e.g., the Internet) are vulnerable to attack. Indeed, attackers have access to a wide range of tools capable of degrading network performance or disabling network resources. Even a single well-targeted data packet may be sufficient to cause an operating system of a network device to crash. Moreover, network devices continue to become more vulnerable to attack as standardized protocols are adopted and implemented.
Because vulnerability to attack is a significant concern to network communities, many techniques have been developed to defend networks and computers (collectively “networks”) from malicious attacks. For example, “computer immunology” is a term used to describe computer-based intrusion detection techniques inspired by biological immune systems. Such intrusion detection techniques are typically designed to detect computing anomalies to identify intrusions into a network. To elaborate, it is a widely accepted theory that a biological immune system is able to distinguish “self” from “other” through clues made up of proteins. In computer immunology, similar theories are applied to networks to distinguish “anomalous” behavior from “normal” behavior. “Normal” behavior may be defined differently but generally refers to observable and acceptable behavior characteristics expected of networks when not under attack. “Anomalous” behavior then refers to any deviation from the defined normal behavior. The detection of anomalous behavior is used to identify intrusion attacks, which tend to cause computer programs to take unusual execution paths.
Several immunology-inspired intrusion detection techniques involve the tracking of system calls to monitor the behavior of computer programs. System calls refer to mechanisms used by computer programs to request service from the operating system (“OS”) of a computer. System calls invoke low-level OS routines that allow the OS to perform restricted actions such as accessing hardware devices (e.g., processors, input and output devices, memory) and other shared machine resources (collectively “shared resources”). Accordingly, the OS (typically the kernel of the OS) is able to allocate and control the shared resources of a computer to fulfill requests received from computer programs.
Conventional system-call-based intrusion detection techniques typically compare monitored system-call sequences with a predefined set of normal system-call sequences to identify occurrences of anomalous sequences. To define the set of normal system-call sequences, sequences of system calls are tracked for a particular computer program as it operates under test conditions (e.g., when the computer or network is not under attack). The tracked system-call sequences are inserted into a database to form a profile of system-call sequences that are considered to be normal operations of the particular program. When the same program operates under real circumstances (e.g., the possibility of attack exists), system-call sequences are monitored and used to identify potential intrusions. In particular, the monitored system-call sequences are compared with the predefined normal system-call sequences stored in the profile database. As long as the monitored system-call sequences have a match in the profile database, operation is considered to be normal. However, if a monitored system-call sequence is not found in the profile database, operation is considered to be anomalous, which may indicate an intrusion attempt.
Unfortunately, several shortcomings are apparent in existing system-call-based intrusion detection techniques. For example, significant delays are inherent in these techniques and may make them impracticable for use with complex computer programs that are processed at high speeds. In particular, it takes time to compare system calls tracked in the OS kernel with data of a profile database stored outside of the OS because communications must be sent back and forth between the OS kernel and the profile database. Because of the sizes of traditional profile databases, it has been impracticable to store them in the OS kernel, which has strict size requirements because, typically, it is continuously operating in main memory.
Moreover, additional delays are introduced by the amount of time required to identify and access the appropriate profile database associated with a particular computer program. Even additional time is required for searching the database, especially when the database is of large size due to the complexity of the particular computer program being monitored. These and other delays tend to render conventional intrusion detection techniques impracticable for many applications, especially applications in which complex programs operate at high processing speeds or when the detection of intrusion attempts is time sensitive.